
Remarks 

Informalities 

Election/Restriction . Claims 1-9 were determined to be subject to restriction as they 
pertain to separate and distinct inventions as follows: 

I. Claims 1 -7, and 9 drawn to a method, classified in class 705, subclass 40. 

II. Claim 8 drawn to an apparatus, classified in class 707, subclass 4. 

A preliminary election was made, without traverse, by Michael F. Krieger on January 14, 
2002 to prosecute Invention group I, claims 1-7, and 9 of the application. Applicant is hereby 
affirming this election. 

Claim Cancellation . Please cancel claim 8 from prosecution on the merits. 
Claim Rejections - 35 U.S.C S 112 

Claims 1 and 9 stand rejected under 35 U.S.C. § 1 12, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject matter which 
applicant regards as the invention. Applicant submits the following to correct this deficiency. In 
response, applicant has amended claims 1 and 9 to correct the deficiencies as recited by the 
Examiner, specifically to provide proper antecedent basis to the claim elements and to correct the 
improper use of passive claim language. 
Claim Rejections ~ 35 U.S.C S 103 

Claims 1-7 and 9 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
United States Patent No. 6,058,380 to Anderson et al., in view of United States Patent No. 
6,018,736 to Gilai et al. In light of the above-identified amendments and the arguments as 
presented below, Applicant submits that neither Anderson, Gilai, nor the combination of these, 
renders the present invention obvious and that the rejection should be withdrawn. 
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As stated in the previous response, Anderson discloses a system and method for 
electronically processing invoice information, as well as requiring an intermediary to perform the 
functions of the invention as disclosed. Specifically, the intermediary in Anderson may be 
termed an invoice collections and payment-type intermediary, which functions to gather invoice 
and other relevant accounts payable information from several customers. This invoice and 
payment information is then used to direct payment to the several vendors corresponding to the 
submitted invoices. The intermediary in Anderson, along with the specific capabilities and 
functions of the type of intermediary disclosed in Anderson, is the central focus of the invention 
and performs the majority of tasks disclosed. 

Anderson allows customers who are not EDI capable to pay vendors electronically 
because vendor invoices are actually physically delivered to the intermediary through traditional 
means, such as mail drop, etc. Once the intermediary has the invoices, payment can be made 
through electronic means or a check can be prepared, which can be mailed to the vendor upon 
approval by the customer. The customer is not required to be EDI capable because the 
intermediary takes care of payment after the customer approves the transaction. See Anderson 
Col. 8, In. 57-67. 

As the invoice collection and payment-type intermediary in Anderson requires each 
customer to submit their invoices to the intermediary, which then is responsible for paying each 
vendor, the customer is essentially taken out of the picture, other than to provide the intermediary 
with the necessary data to complete the transaction. For example, in Anderson all invoices are 
directed to the intermediary, not the customer, which then matches the invoices with vendor 
information and takes care of appropriate payment. 

In the present invention, the fact that a customer may employ an electronic payment 




system on his computer allowing the customer to determine which type of payment method is to 
be employed to pay a particular vendor is not disclosed in Anderson. In the present invention, an 
intermediary of the type described in Anderson is eliminated entirely. The only type of 
intermediary contemplated for use by the present invention system is a processing-only 
intermediary, such as a bank, that is capable of simply sending a paper check to a recipient at the 
request of a customer. A processing-only intermediary is not required to gather physical invoices 
or other information to remit payment, but instead, simply remits payment to a recipient 
according to a request coupled with payment instructions that is communicated to the 
intermediary by one authorized to make such a request (i.e., a customer as described in the 
present invention). In essence, the present invention operates from the standpoint of the 
customer or user, with little or no interaction with the vendor. In the present invention, all 
invoices, etc., are still directed to the customer, who can then use the technology of the present 
invention to pay vendors. 

Also as previously argued, Anderson does not disclose the specific function of 
"determining" a preferred type of payment method for a plurality of vendors as does the present 
invention. According to the disclosure in Anderson, each payment method is not "determined," 
but "pre-determined" or identified in a setup process by one or more ways. See Anderson col. 
10, In. 8-11; col. 13, In. 20-67. This specifically teaches away from the capability of the present 
invention to electronically "determine" a preferred payment method to a vendor based upon 
certain vendor criteria, and then to remit payment to the vendor according to the determined 
payment method, all from the computer system of the customer. Indeed, the invoice collection 
and payment-type intermediary described in Anderson performs a significant portion of the 
payment to the vendor. In addition, there is no suggestion in Anderson pertaining to a method of 
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determining a "preferred payment method" from a plurality of payment methods using an 
electronic system due to the fact that Anderson uses an invoice collection and payment-type 
intermediary that collects the invoices directly as described above. 

On the other hand, the present invention does not require the use of an intermediary in all 
cases. Indeed, if necessary, an intermediary is used when a vendor is incapable of receiving an 
electronic payment. In such a case, the customer is able to determine this using the method as 
claimed in claims 1-9 and then provides payment information to a processing intermediary, such 
as a bank, that then forwards a paper check to the vendor at the request of the customer. 

Claim 1 of the present invention has been amended to clarify and emphasize these 
specific distinctions. Specifically, claim 1 has been amended to make it clear that the method of 
the present invention is substantially performed on the customer's system and not by any other 
entity. Claim 1 recites that the present invention system and method eliminates the need for the 
very type of intermediary as described in Anderson. Thus, Anderson can be said to teach away 
from the present invention as it would not be obvious to one skilled in the art to look to 
Anderson to arrive at the claims of the present invention. Anderson specifically teaches that the 
use of an invoice collection and payment-type intermediary is an integral part of the system 
disclosed, thus making improper a claim that the present invention method and system is 
somehow suggested by Anderson. 

In light of the arguments above and the fact that Anderson does not suggest, nor teach, 
but in fact directly teaches away from that claimed in the present invention, Applicant submits 
that rejection in light of the Gilai reference is moot. Combination of these two references does 
not render the present invention obvious. 
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Conclusion 

Based on the foregoing explanation and amendments to the claims, Applicant submits 
that the deficiencies in the application have been corrected, that the rejections under §§112 and 
103 have been overcome, and that the claims now stand in condition for allowance. 

If any impediment to the allowance of this application remains after entry of these 
amendments and consideration of these remarks, the Examiner is invited to initiate a telephonic 
interview with the undersigned. 

DATED this ~J day of June, 2002. 

Respectfully Submitted, 



neger 



Attorney /for Applicant 
Registrat dn No. 35,232 
KIRTON l& McCONKIE 
1800 EagU Gate Tower 
60 East South Temple 
Salt Lake City, UT 84111 
(801) 328-3600 

CLJ:lah 

ODMA\PCDOCS\DOCS\622500M 
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1 . (Amend e d) A method for allow ina a customer to electronically 

detet mining dctcrminc , in an electronic payment system, which of a plurality of payment methods 
is to be employed for at least one a vendor to be paid, said method comprising the steps of: 

a) receiving from a usc r obtaining at least one vendor identifier for each of said at 

l e as t o ne vendors; 

b) consulting a vendor database for a vendor database identifier corresponding to 

said vendor identifier; 

c) when said v e ndor databas e includ e s said vendor id e ntifier, retrieving a preferred 

payment method identifier corresponding to said vendor database 
identifier as stored in said vendor databaset.when said vendor database 
does not includ e a match o fi ncludes said vendor identifier, from said 
preferred payment method identifier indicating a preferred method of 
payment for said vendor; 

dj phonetically matching said vendor identifie r ph o netically matching to said vendor 
database identifier as stored in said vendor database and retrieving said 
preferred payment method identifierr-arrd when said vendor database does 
not include a match of said vendor identi fier; 

e) presenting to said ttser cu stonier said vendor database identifier in a list 
corresponding to said preferred payment method identifier; 
wh e r e in said m e thod is substantially performed and controlled by th e and 

D performing and executing said method substantially on said customer's computer 

2: (Amended) , thus eliminating the need for an invoice collection and payment 

intermediary. 

2. The method as recited in claim 1, wherein said step of r e c e ivin g obtaining from an 
at l e ast on ea vendor identifier for each of said at l e ast on e vendor step; further comprises the step 
of receiving said at least one vendor identifier for each of said a t least one vendors from an 
accounts payable database created and maintained by an accounting software application. 

3. (Amended) The method as recited in claim I, further comprising the step of 
defining said plurality of payment methods to include traditional check drafting and electronic 
payment methods. 

4. (Amended) The method as recited in claim 1, wherein said step of presenting to 
said user said vendor database identifier in a list corresponding to said preferred payment method 
identifier further comprises the step of when one of said at l e ast on e vendors to be paid is 
proposed for payment using one of said plurality of payment methods, reassigning said one of 
said at least one vendors to another of said plurality of payment methods. 

5. (Amended) The method as recited in claim 1, wherein said presenting to said 
trscr customer said vendor database identifier in a list corresponding to said preferred payment 
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method identifier step further comprises the steps of: 

a) from an identifier of said at least o ne vendors supplied by said trscr customer , 

referencing a database to determine which entries of said database 
correspond identically or most closely to said at least on e vendors supplied 
by said ttscr customcr ; 

b) when said electronic payment system locates an exact match of said identifier of 

said a t leas t one vendor, presenting said at l e ast o ne vendor in normal text 
to said trsercustomer for verification; and 

c) when said electronic payment system finds no exact match of said identifier of 

said at l e ast one vendor, selecting one of said at least on e vendors as an 
approximation of said identifier designating said one of said vendors. 

6. (Am e nd e d) The method as recited in claim 5, wherein said step of selecting one 
of said at l e ast on e vendor as an approximation of said identifier step-further 
comprising compriscs the step o f when on e of said at l e as t on e vendor is presented conspicuously 
from normal, allowing said user to evaluate said approximation to determine if said 
approximation of said identifier accurately reflects said one of said at least one vendor desired by 
said user when one of said at least one vendor is presented conspicuously from normal . 

7. (Amend e d) The method as recited in claim 1, further comprising the step of 
receiving a list of said at least one vendors as output from an accounting software application 
independent from said electronic payment system. 

8: A r e mittanc e delivery syst e m, comprising : 

a re mittance pr e ference databas e storing information pertaining to at l e ast one r e mittance 

recipient; 

a translat i on e ngin e for r e c ei ving pref e rr e d payment information data and r e mittance data 

and translat i ng and formatting said remittance data into on e p r eferred formats; and 

a remittance gene r ating e ngine that rec e iv e s said and forwards said formatted r e mittance 

data to said at least one r e m i ttance r ecip ie nt based on the information stored in 
said remittanc e pref e rence da t abase. 

9. A method for allowing a customer to electronically determine which of a plurality 
o f payment methods is to be used to pav a vendor, and to transmit remittance data paying a 
v e nd o r and t ransmit ti ng r e m i t t ance data , each using an electronic system, said method 
comprising the steps of: 

a] receiving obtaining an outstanding invoice from at l e ast o ne a vendor; 

b] processing said invoice through a computerized accounting application program 
to output accounts payable check data; 

c] assigning said at l e ast one vendor a vendor identifier; 
based upon said accounts payable ch e ck data, 

dj determining whether to pay said vendor by paper check or electronically by 

consulting a vendor database for a vendor database identifier corresponding to 
said vendor identifier , said step of determining based upon said accounts payable 
check data; 
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c] retrieving a preferred payment method identifier when said vendor database 
includes said vendor identifier, r etriev i ng a pref c rrcd said payment method 
identifier corresponding to said vendor database identifier as stored in said vendor 
database; 

when said vendo r databas e docs not include a match of 
0 phonetically matching said vendor identifie r, fr o m said v e ndor i dentifier, 

phonetically matchin g to said vendor database identifier as stored in said vendor 

database and subsequently retrieving said preferred payment method identifier, 

said step of phoneiicallv matching occurring when said vendor database does not 

include a match of said vendor identifier; 
g) presenting to said ttscr customer said vendor database identifier in a list 

corresponding to said preferred payment method identifier; 
hj paying said vendor according to said preferred payment method identifier; 
i] storing, in a remittance preference database, remittance data pertaining to at l e ast 

orrca remittance recipient; 
jj translating and formatting, via a translation engine, said remittance data into one 

of a plurality of preferred formats;-and 
kj forwarding, via a remittance generating engine, said formatted remittance data 

received from said translation engine to said a t l e ast o ne remittance recipient 

based on the information stored in said remittance preference database; 
wh e rein said m e thod is substan t ially pe r fo r med and c o nt r olled by th e and 

D performing and executing said method substantially on said customer's computer 

system of said us e r. , thus eliminating the need for an invoice collection and 

pa yment intermediary. 



622506.1 



- 13- 



